Development Procedure

Type: Documentation

Author: Valentin

---

Working Framework

This document defines a clear working framework for everyone involved in the project (developers, project leads, QA, etc.). It covers sprint organization, development workflow, branching and commit rules, testing and code review best practices, and version control.

Goals:

• Ensure smooth communication across the team.
• Maintain clean, testable, and maintainable code.
• Guarantee reliable CI/CD pipelines.
• Provide clarity on the roadmap and product evolution.

---

Toolchain Versions

• Unreal Engine: Version 5.4 (potentially 5.5 depending on release and plugin compatibility).

Note: Migration to 5.5 requires compatibility checks and review of official release notes.

• Primary Language: C++ for complex systems, Blueprints for quick prototyping and gameplay logic.

• Other Tools:

  • Version control: Git (GitLab)
  • CI/CD system: —— (TBD)
  • Testing and coverage tools: —— (TBD)

---

Plugins & Templates

Templates

• Story Framework: Version 2.0 (previously 1.21)

Plugins

• —— (To be defined)

---

Collaboration

Sprint Management

• Sprint length: 2 weeks

Sprint duration is fixed for better planning and estimation.

• Sprint Goal: Define a clear objective per sprint (e.g., a major feature or demo-ready milestone).

Daily Stand-ups

• Frequency: Daily (adjusted for team availability)
• Duration: Max 20 minutes
• Objective:
  • What was done yesterday
  • What is planned today
  • Any blockers?

Weekly Meetings

• Frequency: Weekly
• Duration: 30 min to 1.5 hrs
• Objective:
  • Detailed technical progress review
  • Discussion on architecture, performance, and design
  • Knowledge sharing

Sprint Review

• Frequency: End of each sprint
• Duration: 30 min to 1 hr
• Objective:
  • Showcase deliverables
  • Collect feedback
  • Assess overall quality

Retrospective

• Frequency: After Sprint Review (or a few days later)
• Duration: 30 min to 1 hr
• Objective:
  • Reflect on the sprint
  • Identify what worked or failed
  • Define action items for improvement

Backlog Management

• Maintain a prioritized, well-defined backlog
• Each task includes:
  • Clear description
  • Priority level
  • Effort estimate (time/points)

Backlog Refinement

• Frequency: 1-2 times per sprint
• Objective:
  • Re-evaluate priorities and complexity
  • Keep backlog updated and realistic

---

Branch Management

Inspired by Git Flow and Conventional Branch Naming:

Main Branches

• master: always contains stable, release-ready code. No direct commits allowed. Merged from develop on release.
• develop: main branch for ongoing work
• production: reflects deployed official builds

Feature Branches

• Format: type/scope/description
• Types: feat, fix, refactor, chore, etc.
• Examples:
  • feat/animations/add_movement_player
  • fix/ui/fix_menu_navigation

Regex Naming Convention

^(feat|fix|docs|style|refactor|perf|test|chore|build|ci|release|workflow)\/[a-z0-9]+\/[a-z0-9_]+$

---

Commits & Pushes

Following the Conventional Commits standard:

Format

<type>(<scope>): <short imperative description>

• Types: feat, fix, refactor, docs, test, chore, etc.
• Examples:
  • feat(Project): Init project
  • fix(menu): fix crash on pause menu
  • refactor(animations): reorganize movement blueprints

Regex for Commits

^(feat|fix|docs|style|refactor|perf|test|chore|build|ci|release|workflow)(\([a-zA-Z\-]+\))?: .+$

---

Issues / Tickets

Each issue must include:

1. Concise Summary
2. Validation Criteria (clear conditions to close the issue)
3. Optional Info: links, references, constraints, or estimates

A template will be available to ensure consistent issue formatting.

---

Testing Guidelines

General Rules

• Code merged into develop must be tested (unit/functional)

Blueprint Testing

• Use UE’s Automation Framework
• Reference: Reddit thread on UE5 Blueprint Unit Testing
• Optionally integrate third-party testing plugins

C++ Testing

• Setup a coverage framework
• CI should enforce minimum coverage (60–80%)

Manual QA

• Required for gameplay
• Sprint-specific QA checklists to be defined

---

Code Review & Merge Process

Requirements

• At least one reviewer (lead or dev)

Steps

1. Submit a Pull Request / Merge Request with a clear description
2. Reviewer checks:
   • Code quality
   • Test coverage
   • Logical integrity
3. CI must pass (compilation, lint, tests, etc.)

Optional: Live Review

• Used for large features
• The dev presents the code live and gathers feedback

Merge Guidelines

• Feature branches → develop
• Hotfixes → master and develop

Merge Permissions

Branch	Merge Allowed By	Push Allowed By
master	Devs / Maintainers	Nobody
production	Maintainers + PM	Nobody

Merge Request Naming

• Include issue ID in square brackets
• Example: feat(3C): Implement 3C's [#3]

---

Unreal Engine — Asset Naming & Folder Structure

Folder Structure

• Organize by functionality or category (Characters, UI, Environments, etc.)
• Subfolders by type: Meshes, Textures, Animations, etc.

Content
├── Characters
│   ├── Common
│   │   ├── Animations
│   │   ├── Audio
│   ├── Bob
│   ├── Zoe
├── Art
│   ├── Nature
│   │   ├── Rocks
│   │   ├── Trees
├── Effects
│   ├── Fire
│   ├── Electrical
├── Core
│   ├── Engine
│   ├── Interactables
├── Maps
│   ├── Campaign1
├── Weapons
│   ├── Pistols
│   ├── Rifles

Naming Conventions

Prefix	Type	Example
BP_	Blueprint	BP_PlayerCharacter
T_	Texture	T_Enemy_Diffuse
SM_	Static Mesh	SM_Tree01
SK_	Skeletal Mesh	SK_MainHero
MAT_	Material	MAT_Skybox

See full guide: Allar's UE5 Style Guide

---

Versioning

Follow the MAJOR.MINOR.PATCH format.

• Major: Breaking changes / full engine upgrade
• Minor: New features
• Patch: Bug fixes and small updates

Example

• 1.0.0 → Initial release
• 1.1.0 → New feature
• 1.1.1 → Patch
• 2.0.0 → Unreal upgrade or full refactor

---

This document is to be reviewed and updated continuously as the project evolves.